Data model simplification through field fallout

ABSTRACT

The present invention generally provides methods, articles of manufacture and systems for simplifying a query building process by limiting the number of fields presented to a user for building queries. The number of fields presented to the user may be limited by hiding one or more logical fields from the user based on usage characteristics. For example, a logical field that is rarely used or has not been used within a predetermined period of time may be hidden from the user. For some embodiments, a fallout manager may monitor the use of logical fields in building queries, update usage characteristics, and mark logical fields as hidden based on the usage characteristics. A graphical user interface may not present to a user logical fields that have been marked as hidden.

BACKGROUND OF THE INVENTION

[0001] 1. Field of the Invention

[0002] The present invention generally relates to data processing andmore particularly to simplifying the process of building databasequeries by limiting the number of fields presented to a user forbuilding the database queries.

[0003] 2. Description of the Related Art

[0004] Databases are computerized information storage and retrievalsystems. A relational database management system is a computer databasemanagement system (DBMS) that uses relational techniques for storing andretrieving data. The most prevalent type of database is the relationaldatabase, a tabular database in which data is defined so that it can bereorganized and accessed in a number of different ways. A distributeddatabase is one that can be dispersed or replicated among differentpoints in a network. An object-oriented programming database is one thatis congruent with the data defined in object classes and subclasses.

[0005] Regardless of the particular architecture, in a DBMS, arequesting entity (e.g., an application or the operating system) demandsaccess to a specified database by issuing a database access request.Such requests may include, for instance, simple catalog lookup requestsor transactions and combinations of transactions that operate to read,change and add specified records in the database. These requests aremade using high-level query languages such as the Structured QueryLanguage (SQL). Illustratively, SQL is used to make interactive queriesfor getting information from and updating a database such asInternational Business Machines' (IBM) DB2, Microsoft's SQL Server, anddatabase products from Oracle, Sybase, and Computer Associates. The term“query” denominates a set of commands for retrieving data from a storeddatabase. Queries take the form of a command language that letsprogrammers and programs select, insert, update, find out the locationof data, and so forth.

[0006] Queries are constructed of query conditions that serve to filterresults returned from the query. Accordingly, a query may be thought ofas group of filters put together to sift out only the data in which theyare interested. Query conditions are typically constructed by specifyingconditional operations on one or more fields in the targeted database.To facilitate query building, some applications may provide the userwith a graphical user interface (GUI) presenting the user with a list offields for use in specifying query conditions.

[0007] However, as the relative size and complexity of a data modelincreases, the number of fields presented to the user in the GUI maybecome unwieldy. In other words, the data model may easily grow beyondthe ability for users to understand and use it. Typically, at least someof the fields presented in the GUI may be rarely (or never) used inbuilding a query. By presenting these rarely used fields to the user,usability of the application targeting the data model suffers, as theGUI becomes too complex for the user to be able to see and understandhow they might build a query to return desired data.

[0008] Accordingly, there is a need for an improved method forsimplifying the query building process by limiting the number of fieldspresented to the user for building queries.

SUMMARY OF THE INVENTION

[0009] The present invention generally provides methods, articles ofmanufacture and systems for simplifying a query building process bylimiting the number of fields presented to a user for building queries.

[0010] For some embodiments, a method of accessing data generallyincludes providing an interface allowing a user to build a databasequery based on a plurality of fields, monitoring use of the fields inbuilding queries, and limiting fields presented to the user in theinterface based on the monitored use of the fields in building queries.

[0011] For some embodiments, a method of providing access to data havinga particular physical data representation generally includes providingan interface allowing a user to build a database query based on aplurality of logical fields corresponding to physical entities of theparticular physical data representation, monitoring use of the logicalfields in building queries, and limiting the logical fields presented tothe user in the interface based on the monitored use of the logicalfields in building queries.

[0012] For some embodiments, the article of manufacture generallyincludes a computer-readable medium containing a program which, whenexecuted by a processor, performs operations for accessing data. Theoperations generally include providing an interface allowing a user tobuild a database query based on a plurality of logical fields mapped tophysical entities of the particular physical data representation,monitoring use of the logical fields in building queries, and limitingthe logical fields presented to the user in the interface based on themonitored use of the logical fields in building queries.

[0013] For some embodiments, the system generally includes a database, adata repository abstraction layer, a query building interface, and afallout manager. The data repository abstraction layer may generallycontain logical fields corresponding to physical entities of thedatabase. The query building interface may be configured to allow a userto build a query to access the database by specifying query conditionsbased on the logical fields of the data repository abstraction layer.The fallout manager may be configured to control the logical fieldspresented by the query building interface based on usage characteristicsof the logical fields in building queries.

BRIEF DESCRIPTION OF THE DRAWINGS

[0014] So that the manner in which the above recited features,advantages and objects of the present invention are attained and can beunderstood in detail, a more particular description of the invention,briefly summarized above, may be had by reference to the embodimentsthereof which are illustrated in the appended drawings.

[0015] It is to be noted, however, that the appended drawings illustrateonly typical embodiments of this invention and are therefore not to beconsidered limiting of its scope, for the invention may admit to otherequally effective embodiments.

[0016]FIG. 1 is a computer system illustratively utilized in accordancewith the present invention.

[0017]FIG. 2 is a relational view of software components of oneembodiment of the present invention.

[0018]FIG. 3 is a flow chart illustrating exemplary operations formarking as hidden, or removing, fields in accordance with the presentinvention.

[0019] FIGS. 4A-4B are exemplary graphical user interface (GUI) screensfor building a database query in accordance with the present invention.

[0020] FIGS. 5A-5B are flow charts illustrating exemplary operations forlimiting the number of fields presented to a user and updating usagecharacteristics of fields, respectively, in accordance with the presentinvention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0021] The present invention generally is directed to systems, methodsand articles of manufacture for simplifying the building of queries foraccessing data in a data repository by limiting the number of fieldspresented to a user based on usage characteristics of the logicalfields. In some embodiments, a data repository abstraction (DRA) layerprovides a logical view of the data repository that is independent ofthe particular manner of data representation. The DRA layer may beactively managed to hide or remove logical fields that are not accessedoften (or are not accessed within a predetermined period of time). Byhiding or removing logical fields from the DRA layer, the number oflogical fields presented to a user in a query building interface may belimited, thus simplifying the query building process. Further, byremoving logical fields from the DRA layer altogether, the size of theDRA layer and associated processing overhead may be reduced, thusimproving performance.

[0022] As used herein, the term database generally refers to anycollection of data, regardless of the particular physical representation(or “schema”) and the terms database and data source may be usedinterchangeably. The term schema generically refers to a particulararrangement of data. In other words, a database may be organizedaccording to a relational schema (accessible by SQL queries), an XMLschema (accessible by XML queries), or any other schema presently knownor to be developed. The term abstract query generally refers to a querycomposed of logical fields that may be mapped to physical entities of adatabase, regardless of a particular underlying physical representation.Embodiments of the present invention may be used to advantage whenbuilding abstract queries or conventional database queries. However, tofacilitate understanding, embodiments of the present invention will bedescribed below with reference to building abstract queries. Further,the abstract queries described below may target a medical industrydatabase as a particular, but not limiting, application example.

[0023] One embodiment of the invention is implemented as a programproduct for use with a computer system such as, for example, thecomputer system 110 of the data processing environment 100 shown in FIG.1 and described below. The program(s) of the program product definesfunctions of the embodiments (including the methods described herein)and can be contained on a variety of signal-bearing media. Illustrativesignal-bearing media include, but are not limited to: (i) informationpermanently stored on non-writable storage media (e.g., read-only memorydevices within a computer such as CD-ROM disks readable by a CD-ROMdrive); (ii) alterable information stored on writable storage media(e.g., floppy disks within a diskette drive or hard-disk drive); or(iii) information conveyed to a computer by a communications medium,such as through a computer or telephone network, including wirelesscommunications. The latter embodiment specifically includes informationdownloaded from the Internet and other networks. Such signal-bearingmedia, when carrying computer-readable instructions that direct thefunctions of the present invention, represent embodiments of the presentinvention.

[0024] In general, the routines executed to implement the embodiments ofthe invention, may be part of an operating system or a specificapplication, component, program, module, object, or sequence ofinstructions. The software of the present invention typically iscomprised of a multitude of instructions that will be translated by thenative computer into a machine-readable format and hence executableinstructions. Also, programs are comprised of variables and datastructures that either reside locally to the program or are found inmemory or on storage devices. In addition, various programs describedhereinafter may be identified based upon the application for which theyare implemented in a specific embodiment of the invention. However, itshould be appreciated that any particular nomenclature that follows isused merely for convenience, and thus the invention should not belimited to use solely in any specific application identified and/orimplied by such nomenclature.

[0025] Referring now to FIG. 1, the data processing environment 100 isshown. In general, the data processing environment 100 includes acomputer system 110 and a plurality of networked devices 146. Thecomputer system 110 may represent any type of computer, computer systemor other programmable electronic device, including a client computer, aserver computer, a portable computer, an embedded controller, a PC-basedserver, a minicomputer, a midrange computer, a mainframe computer, andother computers adapted to support the methods, apparatus, and articleof manufacture of the invention. In one embodiment, the computer system110 is an eServer iSeries 400 available from International BusinessMachines of Armonk, N.Y.

[0026] The computer system 110 could include a number of operators andperipheral systems as shown, for example, by a mass storage interface137 operably connected to a direct access storage device (DASD) 138, bya video interface 140 operably connected to a display 142, and by anetwork interface 144 operably connected to the networked devices 146.The display 142 may be any video output device for outputting viewableinformation. The networked devices 146 may be any combination of anytype networked devices, such as networked servers, networked printers,and network accessed storage (NAS) devices.

[0027] Computer system 110 is shown comprising at least one processor112, which obtains instructions and data via a bus 114 from a mainmemory 116. The processor 112 could be any processor adapted to supportthe methods of the invention. The main memory 116 is any memorysufficiently large to hold the necessary programs and data structures.Main memory 116 could be one or a combination of memory devices,including Random Access Memory, nonvolatile or backup memory, (e.g.,programmable or Flash memories, read-only memories, etc.). In addition,main memory 116 may be considered to include memory physically locatedelsewhere in a computer system 110, for example, any storage capacityused as virtual memory or stored on a mass storage device (e.g., DASD138) or on another computer coupled to the computer system 110 via bus114.

[0028] The main memory 116 is shown configured with an operating system118. The operating system 118 is the software used for managing theoperation of the computer system 110. Examples of the operating system118 include UNIX, Microsoft Windows®, and the like. As illustrated, themain memory 116 further includes at least one application 120 and anabstract query interface 130.

[0029] The application 120 and the abstract query interface 130 aresoftware products comprising a plurality of instructions that areresident at various times in various memory and storage devices in thecomputer system 110. When read and executed by one or more processors112 in the computer system 110, the application 120 and the abstractquery interface 130 cause the computer system 110 to perform the stepsnecessary to execute steps or elements embodying the various aspects ofthe invention. The application 120 (and more generally, any requestingentity, including the operating system 118) is configured to run (i.e.,issue/execute) queries against the database 139.

[0030] The queries issued by the application 120 may be created and/orspecified by a user via a query building interface 122, which may beincluded with the application 120. The queries (referred to herein as“abstract queries”) are composed using logical fields defined by theabstract query interface 130. The query building interface 122 may allowthe user to generate abstract queries by specifying query conditions,based on the logical fields, to be added to the abstract queries. Thelogical fields used in the abstract queries are defined by a datarepository abstraction (DRA) component 132 of the abstract queryinterface 130. The abstract queries are executed by a runtime component136 which transforms the abstract queries into a form consistent withthe physical representation of the data contained in the database 139.The concepts of data abstraction and abstract queries are described indetail in the commonly owned, co-pending application Ser. No.10/083,075, entitled “Improved Application Portability And ExtensibilityThrough Database Schema And Query Abstraction,” filed Feb. 26, 2002,herein incorporated by reference in its entirety.

[0031] The abstract queries created by the query building interface 122and executed by the runtime component 136 may be monitored by a falloutmanager 134 of the abstract query interface 130. As will be described ingreater detail below, the fallout manager 134 may be generallyconfigured to modify the DRA component 132 by removing logical fieldsand/or marking logical fields as hidden, based on usage characteristicsof the logical fields as detected in the monitored abstract queries. Aspreviously described, by removing fields from the DRA component 132and/or marking fields as hidden, the number of fields presented to auser, by the query building interface 122, for use in building anabstract query by query building interface 122 may be reduced, which maysimplify the query building process.

Data Model Fallout

[0032] The fallout manager 134 may limit the number of fields presentedto the user by allowing fields that have not been used recently (or areused infrequently) to “fall-out” of the DRA component 132. As usedherein, the term fall-out generally refers to preventing a field frombeing presented to the user by either marking the field as hidden(referred to as “partial fall-out”) in the DRA component 132 or removingthe field completely from the DRA component 132 (referred to as“complete fall-out”). In the case of partial fall-out, a field is hiddenfrom the user (e.g., not presented to the user in the interface), butstill remains in the DRA component 132. In some cases, hidden fields maystill be displayed, for example, upon user request. In the case ofcomplete fall-out, the field is actually removed from the DRA component132 and may not be displayed unless first restored to the DRA component132, for example, by an administrator.

[0033]FIG. 2A illustrates a relational view of the DRA component 132,fallout manager 134, and query execution component 136, according to oneembodiment of the invention. As illustrated, the DRA component 132includes a set of logical fields corresponding to fields in a physicaldata representation 214. The physical data representation 214 may be arelational data representation (as shown), such as SQL, for example.Regardless of the actual physical data representation, a user maygenerate, via the query building interface 122, an abstract query 202including query conditions based on the logical fields of the DRAcomponent 132, in order to access data stored in the physical datarepresentation 214. As illustrated, for some embodiments, logical fieldsmay be organized in categories (e.g., Contacts, Birth and Age Relatedfields, etc.). The concepts described herein may also be applied tolimit the number of categories presented to a user.

[0034] The query execution component 136 is generally configured toexecute the abstract query 202 by transforming the abstract query 202into a concrete query compatible with the physical data representation214. The query execution component 136 may transform the abstract query202 into the concrete query by mapping the logical fields of theabstract query 202 to the corresponding physical fields of the physicaldata representation 214, based on mapping information in the DRAcomponent 132. The mapping abstract queries to concrete queries isdescribed in detail in the previously referenced co-pending applicationSer. No. 10/083,075.

[0035] For example, as illustrated in FIG. 2B, the DRA component 132 mayinclude, for each logical field, table and field names indicating acorresponding physical field in the physical data representation 214.The DRA component 132 may also include, for each logical field, aBoolean HIDDEN attribute to indicate to the query building interface 122whether the logical field should be hidden (not displayed) and aparameter to store a usage characteristic of the logical field. Forexample, as shown, a value indicative of the last use of the logicalfield (e.g., as a number of days) may be stored as the usagecharacteristic parameter. Alternatively, a time stamp indicative of thelast use may be stored in the usage characteristic which may be used tocalculate the amount of time has past since the last use from a currenttime stamp. For some embodiments, usage characteristics may include afrequency with which the logical field is used, for example, as definedby a number of times the logical field has been used in a query for agiven period. Further, as will be described in greater detail below, forsome embodiments, usage characteristics for individual users may bestored in one or more DRA components 132, allowing for user-specificfallout.

[0036] Referring back to FIG. 2A, the fallout manager 134 may decidewhether a logical field should partially or completely fallout of theDRA component 132 based on one or more scheduling algorithms 135. Thescheduling algorithms 135 may include a set of parameters that determinehow and when logical fields should fallout (partially or completely) ofthe DRA component 132. As illustrated in FIG. 2C, for some embodiments,the scheduling algorithms 135 may include threshold parameters forcomparison against the usage characteristic parameters stored in the DRAcomponent 132 to determine fallout.

[0037] As illustrated, a first scheduling algorithm may cause logicalfields whose last use occurred more than 180 days ago to partiallyfallout. As a result, BIRTH DATE and AGE IN YEARS fields in the DRAcomponent 132, last used more than 180 days ago, may be marked as hidden(e.g., the HIDDEN attribute may be set to YES). A second schedulingalgorithm may cause logical fields whose last use occurred more than 365days ago to completely fallout. As a result, STREET and AGE IN DECADESfields last used more than 365 days ago may-be removed from the DRAcomponent 132. As illustrated in FIGS. 2A and 2D, the removed fields andthe associated parameters may be stored in the fallout information 138.

Fall Out Maintenance

[0038] The fallout manager 134 may be generally configured to performtwo basic functions: to monitor the query building process to updateusage characteristics for logical fields and to maintain (update) theDRA component 132 by allowing logical fields to fall out of the DRAcomponent 132 based on the usage characteristics. For some embodiments,the fallout manager 134 may parse abstract queries 202 issued by thequery building interface 122 to determine the logical fields used inconstructing the abstract query 202. For other embodiments, the queryexecution component 136 may send the fallout manager 134 informationregarding the logical fields used to construct the abstract query 202.Regardless, the fallout manager 134 may update the usage characteristicsstored in the DRA component 132 for each of the logical fields used toconstruct the abstract query 202.

[0039]FIG. 3 is a flow diagram of operations 300 that may be performedby the fallout manager 134 for maintaining the DRA component 132. Theoperations 300 may be described with reference to FIGS. 2A-2D. Theoperations 300 begin at step 302, for example, in the course ofperforming periodic maintenance on the DRA component 132 or in responseto a request to perform DRA maintenance (e.g., from an administrator).Further, the operations 300 may be performed automatically, for example,prior to invoking the query building interface 122, to update the DRAcomponent 132. Regardless, at step 304, the fallout manager 134 enters aloop of operations (including steps 306-326) performed for each field inthe DRA component 132.

[0040] At step 306, last use data is retrieved for the selected field.At step 308, the fallout manager 134 determines (based on the last usedata) if the field has been used to build a query within a predeterminedpartial fallout time period (T_(PARTIAL)). As previously described, lastuse data may be stored as a usage characteristic parameter for eachfield in the DRA. As previously described, the last use data may bestored in any suitable format, such as the actual amount of time thathas passed since the field was last used (e.g., in days, as shown) or asa time stamp recorded when the field was last used. Regardless of theformat, if the field has been used to build a query within T_(PARTIAL),processing continues to step 304 to select the next field.

[0041] On the other hand, if the field has not been used to build aquery within T_(PARTIAL), the field is marked as hidden at step 312. Forexample, the HIDDEN attribute for the field may be set to YES. At step314, the fallout manager 134 determines if the selected field is thelast field in a category (or parent field). If so, the category ismarked as hidden, at step 316. For example, while not illustrated inFIG. 2B, the DRA component 132 may also include, for each category, aHIDDEN attribute similar to the HIDDEN attribute of the logical fields.As will be described in greater detail below, the query buildinginterface 122 may determine whether or not to display a field (orcategory) based on the value of a corresponding HIDDEN attribute.

[0042] At step 318, the fallout manager determines if the field has beenused to build a query within a predetermined complete fallout timeperiod (T_(COMPLETE)). If the field has been used to build a querywithin T_(COMPLETE), processing continues to step 304 to select the nextfield.

[0043] On the other hand, if the field has not been used to build aquery within T_(COMPLETE), the field is removed from the DRA component132, at step 320. At step 322, the fallout manager determines if theselected field (removed from the DRA in step 320) was the last field ina category remaining in the DRA component 132. If so, the category isremoved from the DRA component 132, at step 324. At step 326, thefallout information 138 is updated and processing continues to step 304to select the next field for processing. Once all the fields have beenprocessed, the operations 300 are exited at step 330.

[0044] As illustrated in FIG. 2D, the fallout information 138 maycontain all the information regarding the removed fields, that waspreviously contained in the DRA component 132. An advantage to thisapproach is that the removed fields may be restored to the DRA component132 from the fallout information 138, for example, upon request of adatabase administrator. Another advantage to this approach is that thelast use data may continue to be updated even after a field is removed.Accordingly, if a scheduling algorithm is changed (or a differentscheduling is used), resulting in a greater complete fallout time,removed fields that were last used prior to the greater complete fallouttime may be automatically restored.

[0045] Of course, the particular operations 300 illustrated and theparticular order of the operations 300 is for illustrative purposesonly, and may be modified in various ways. For example, for someembodiments, usage characteristics of a field may be tested for completefallout prior to testing for partial fallout. As another example, forsome embodiments, fallout processing may not be performed on categories(i.e., steps 314-316 and steps 322-324). For example, for someembodiments, fields may not be organized in categories.

Query Building Interface

[0046] The impact of field fallout from a user's perspective isillustrated in FIGS. 4A and 4B, which show an exemplary GUI screen 530for adding search conditions to a query based on fields from the DRAcomponent 132, without and with hidden fields shown, respectively. TheGUI screen 530 for adding search conditions may be accessed, forexample, from a main query building GUI screen of the query buildinginterface 122. Of course, the GUI screen 530 of FIGS. 4A and 4Billustrate only one embodiment of the present invention, and manydifferent variations of suitable GUI screens may allow a user to addsearch conditions to a query within the scope of the present invention.For illustrative purposes only, the FIGS. 4A and 4B will be describedwith reference to building queries to a database containing fieldsrelated to the medical industry. Of course, similar GUI screens may becreated for building queries to databases containing fields related toany industry.

[0047] The GUI screen 530 may present to the user fields for use inconstructing search conditions to be added to a query being built. Asillustrated, the GUI screen 530 may present the fields within a set ofcategories. The set of categories may depend on the industry for whichthe database is established. For example, for a medical industrydatabase application, the list of categories may include a BIRTH AND AGERELATED category 532, a LABARATORY RESULTS category 534, a REPORTScategory 536, and a DIAGNOSTIC CODE category 538 (as illustrated, theDIAGNOSTIC CODE category 538 may allow a user to enter governmentmandated ICD-9 diagnostic codes). Each of the categories may have a listof related fields (or related subcategories with related fields).

[0048] For example, the BIRTH AND AGE RELATED category 532 may includefields for AGE, BIRTH DATE, and AGE IN DECADES. To construct a querycondition based on one of the fields, the end user may select one of thefields (e.g., from a pull down menu). In response to selecting one ofthe fields, the user may be presented with another GUI screen (notshown) allowing the user to specify a query condition based on theselected field. For example, one such GUI screen may allow the user toenter an age related search condition by specifying a logical operatorand a number of years (e.g., AGE>40). Of course, age is typically notstored in a database, but rather calculated from a birth date andcurrent date. However, the query building interface 122 may hide thisdetail from a user, greatly facilitating the entry of age relatedconditions.

[0049] As previously described, a user may be given the option ofdisplaying hidden fields. For example, the GUI screen 530 may include aSHOW HIDDEN FIELDS check box 544. With the check box 544 unchecked(i.e., SHOW HIDDEN FIELDS disabled), in FIG. 4A, hidden fields are notpresented to the user. For example, a hidden field AGE IN DECADES is notpresented in the pulldown menu for the BIRTH AND AGE RELATED categories532, and a hidden CONTACTS category 539 (i.e., a category with onlyhidden fields) is not displayed. As illustrated in FIG. 4B, however,with the check box 544 checked, the hidden fields (i.e., AGE IN DECADESand the fields of the hidden category CONTACTS) are presented to theuser, for example, regardless of the value of the corresponding HIDDENattributes.

[0050] It should be noted, however, that fields that were removed fromthe DRA component 132 (i.e., fields that fell out completely) are notdisplayed regardless of whether the check box 544 is checked or not.However, as previously described, removed fields may be restored (basedon the fallout information 138) to the DRA component 132. For someembodiments, the removed fields may be restored to the DRA component 132as hidden or unhidden (e.g., by initializing the corresponding HIDDENattribute accordingly).

[0051]FIGS. 5A and 5B are flow diagrams of operations 500 and 550,respectively, that may be performed as part of the query buildingprocess. The operations 500 may be performed, for example, by the querybuilding interface 122, to limit the number of fields presented to auser, for example, in an effort to simplify the query building process.The operations 550 may performed during normal query building andexecution process, for example, by the fallout manager 134, tocontinuously update usage characteristics of fields in the DRA component132.

[0052] The operations 500 begin at step 502, for example, when buildinga GUI screen (such as the GUI screen 530 of FIGS. 4A and 4B) to presentfields to the user for use in adding search conditions, or as aninitialization routine to identify fields to be displayed at a latertime. At step 504, a loop of operations (steps 506-516) are performedfor each field in the DRA component 132 is entered, to determine whichof the fields should be presented to the user. At step 506, adetermination is made of whether a selected field is marked as hidden.For example, the determination may be made by testing the Boolean hiddenparameter for the field in the DRA component 132. If the field is markedas hidden, a determination is made, at step 508, whether the user hasrequested that hidden fields be shown (e.g., via the check box 544 ofthe GUI 530). If either the field is not marked as hidden or the userhas requested that hidden fields be shown, the field is displayed atstep 510 (or added to a list of fields to be displayed) and processingcontinues to step 504 to select the next field.

[0053] If, on the other hand, the field is marked as hidden and the userhas not requested hidden fields to be shown, the field is not displayedat step 512 (or the field is not added to the of fields to bedisplayed). Optionally, at step 514, a determination is made of whetherthe field is the last field in a category (i.e., all other fields in thecategory are also hidden). If so, the category is not displayed, at step516, and processing continues to step 504 to select the next field.

[0054] As previously described with reference to FIG. 3, categories mayalso be marked as hidden during fallout processing by the falloutmanager 134. For example, each category may have a Boolean hiddenparameter that may be tested to determine if the category is hidden.Therefore, rather than make the determination of step 514, adetermination may be made of whether the category is hidden or not. Ofcourse, this determination may be made in an outer loop (not shown),such that the operations 504-510 are not performed for fields of hiddencategories.

[0055] Once it has been determined which fields (or categories) are tobe displayed, processing proceeds from step 504 to the operations 550 ofFIG. 5B for updating usage characteristics of fields, by the falloutmanager 134, during the query building and/or execution process. Theoperations 550 begin at step 552 when a user builds a query. For someembodiments, the fallout manager 134 may receive the query from thequery building interface 122 when a user chooses to execute a query. Forother embodiments, rather than receive the query, the fallout manager134 may receive a list of fields used in the query from the queryexecution component 136. Regardless, at step 554, the fallout manager134 enters a loop of operations (including steps 556-559) performed foreach field in the query. At step 556, the usage characteristics (e.g.,last use or frequency of use) for a selected field is updated. Forexample, the last use parameter for the selected field may be updated inthe DRA component 132.

[0056] For some embodiments, related fields may be correlated, such thatthe usage characteristics of the correlated fields are updated together.Fields may be correlated if, for example, the use of one of the fieldsincreases the likelihood of the use of another one of the fields.Accordingly, when the usage characteristics of one field is updated, theusage characteristics of any correlated fields may also be updated.Therefore, at step 558, a determination is made whether the selectedfield is correlated with other fields. If the selected field is notcorrelated with other fields, processing proceeds to step 554 to selectthe next field. If the selected field is correlated with other fields,the usage characteristics of the correlated fields are updated, at step559, and processing proceeds to step 554 to select the next field. Oncethe usage characteristics for each field in the query (and anycorrelated fields) have been updated, the operations are exited at step560.

User-Specific Fallout

[0057] As previously described, for some embodiments, usagecharacteristics may be maintained for individual users. Thus, forexample, the operations 550 may be performed to update usagecharacteristics for a particular user. In other words, the falloutmanager 134 may maintain user-specific usage characteristics for fieldsin the DRA component 132, and logical fields may be marked as hiddenfrom specific users (i.e., rather than “globally” hidden from allusers). For some embodiments, a separate DRA component 132 may beprovided for each user and the fallout manager 134 may maintain andaccess a separate DRA component 132 to perform fallout for each user.For other embodiments, a global DRA component 132 may include logicalfields with separate usage characteristics for each user in a system.

[0058] Regardless, the operations 500 may be performed to determinewhich fields are displayed for (or hidden from) a particular user basedon the usage characteristics corresponding to the particular user. Thus,different users (running the query building interface 122) may bepresented with correspondingly different logical fields, based on theirindividual usage characteristics. In other words, by performinguser-specific fallout, one or more logical fields presented to one usermay not be presented to another user. User-specific fallout may have thehighly desirable result that (eventually) logical fields that are notinteresting to a particular user may be hidden from that particularuser, without being hidden from other, possibly interested users.

[0059] As an example, two medical researchers, Researcher A andResearcher B may perform research relating to different families ofdiseases, for example, heart disease and liver disease, respectively.Accordingly, Researcher A may build queries with conditions based onlogical fields related to heart disease, but not liver disease, whileResearcher B may build queries with conditions based on logical fieldsrelated to liver disease, but not heart disease. Due to user-specificfallout, logical fields related to liver disease may (eventually) not bepresented to Researcher A, despite the fact that Researcher B mayregularly build queries related to liver disease. Similarly, logicalfields related to heart disease may (eventually) not be presented toResearcher B despite the fact that Researcher A may regularly buildqueries related to heart disease. Of course, logical fields that are notused by either researcher may eventually fallout with respect to both,and may, therefore, not be presented to either.

[0060] Thus, by performing user-specific fallout, the query buildingprocess for Researcher A and Researcher B may be simplified by limiting,independently, the logical fields presented to each. In a similarmanner, user-specific scheduling algorithms may also be utilized. Forexample, the fallout manager 134 may perform DRA maintenance (e.g.,operations 300 of FIG. 3) based on scheduling algorithms specific toparticular users. For some embodiments, users may be able to control therate with which logical fields fallout by adjusting schedulingalgorithms. For example, one user may reduce a fallout period of ascheduling algorithm to allow logical fields to fallout rapidly (e.g.,LAST USE=50 days), while another user may increase a fallout period toallow logical fields to fallout gradually (e.g., LAST USE=100 days).

Conclusion

[0061] By limiting the number of fields presented to a user based onusage characteristics of the fields, the query building process may begreatly simplified. The number of fields presented to the user may belimited by marking fields as hidden and/or removing fields from a datarepository abstraction. It should be noted that any reference herein toparticular values, definitions, programming languages and examples ismerely for purposes of illustration. Accordingly, the invention is notlimited by any particular illustrations and examples. For example, whileaspects of the present invention have been described with reference toan abstract data model (utilizing a data repository abstractioncomponent containing logical fields), the aspects may also be appliedwith advantage to conventional data models having fields correspondingto a particular physical representation. In other words, any type ofquery building interface may be simplified by limiting the number offields presented to a user, regardless of the underlying data model.

[0062] While the foregoing is directed to embodiments of the presentinvention, other and further embodiments of the invention may be devisedwithout departing from the basic scope thereof, and the scope thereof isdetermined by the claims that follow.

What is claimed is:
 1. A method of providing access to data, comprising:providing an interface allowing a user to build a database query basedon a plurality of fields; monitoring use of the fields in buildingqueries; and limiting fields presented to the user in the interfacebased on the monitored use of the fields in building queries.
 2. Themethod of claim 1, wherein limiting the fields presented to the user inthe interface comprises hiding, from the user, fields not used inbuilding queries for a predetermined period of time.
 3. The method ofclaim 1, wherein limiting the fields presented to the user in theinterface comprises hiding, from the user, fields based on a frequencyin which the fields are used in building queries.
 4. The method of claim1, comprising, upon user request, presenting to the user previouslyhidden fields in the interface.
 5. The method of claim 1, whereinmonitoring use of fields comprises, for at least some fields, recordingwhen the fields were last used in building a query.
 6. The method ofclaim 1, wherein monitoring use of fields comprises updating usagecharacteristics for a set of correlated fields when any of the set ofcorrelated fields is used in building a query.
 7. The method of claim 1,wherein monitoring use of the fields in building queries comprises:monitoring use, by a plurality of users, of the fields in buildingqueries; and storing one or more usage characteristics for each of theplurality of users.
 8. The method of claim 7, comprising: presenting afirst set of logical fields to a first user, based on one or more usagecharacteristics for the first user; and presenting a second set oflogical fields to a second user, based on one or more usagecharacteristics for the seconds user, wherein the first set of logicalfields and the second set of logical fields are different.
 9. A methodof providing access to data having a particular physical datarepresentation, comprising: providing an interface allowing a user tobuild a database query based on a plurality of logical fieldscorresponding to physical entities of the particular physical datarepresentation; monitoring use of the logical fields in buildingqueries; and limiting the logical fields presented to the user in theinterface based on the monitored use of the logical fields in buildingqueries.
 10. The method of claim 9, wherein limiting the logical fieldspresented to the user comprises hiding, from the user, logical fieldsnot used in building queries for a predetermined period of time.
 11. Themethod of claim 9, wherein: the logical fields are stored in a datarepository abstraction component; and limiting the logical fieldspresented to the user comprises removing logical fields from the datarepository abstraction component.
 12. The method of claim 11, furthercomprising storing information regarding logical fields removed from thedata repository abstraction component.
 13. The method of claim 12,further comprising restoring a previously removed logical field to thedata repository abstraction component based on stored informationregarding the previously removed logical field.
 14. A computer-readablemedium containing a program which, when executed by a processor,performs operations comprising: providing an interface allowing a userto build a database query based on a plurality of logical fields mappedto physical entities of the particular physical data representation;monitoring use of the logical fields in building queries; and limitingthe logical fields presented to the user in the interface based on themonitored use of the logical fields in building queries.
 15. Thecomputer-readable medium of claim 14, wherein limiting the logicalfields presented to the user in the interface comprises hiding, from theuser, logical fields not used in building queries for a predeterminedperiod of time.
 16. The computer-readable of claim 14, furthercomprising, upon user request, presenting to the user previously hiddenlogical fields.
 17. A database system comprising: a database comprisingdata having a particular physical representation; a data repositoryabstraction layer comprising logical fields corresponding to physicalentities of the database; a query building interface allowing a user tobuild a query to access the database by specifying query conditionsbased on the logical fields; and a fallout manager configured to controlthe logical fields presented by the query building interface based onusage characteristics of the logical fields in building queries.
 18. Thedatabase system of claim 17, wherein the fallout manager is configuredto control the logical fields presented by the query building interfaceto a particular user based on usage characteristics of the logicalfields in building queries by the particular user.
 19. The databasesystem of claim 18, wherein the data repository abstraction layerfurther comprises a plurality of usage characteristics, each specific toa particular user, for one or more of the logical fields.
 20. Thedatabase system of claim 17, wherein the usage characteristics comprisean indication of at least one of: when a logical field was last used inbuilding a query; and a frequency with which the logical field has beenused in building queries.
 21. The database system of claim 20, whereinthe logical fields in the data repository abstraction layer comprise aset of correlated logical fields and the fallout manager is configuredto update usage characteristics of each of the correlated logical fieldsupon detecting a query has been built using any of the set of correlatedlogical fields.
 22. The database system of claim 17, wherein the falloutmanager is configured to control the logical fields presented by thequery building interface by hiding logical fields not used in building aquery within a first predetermined period of time.
 23. The databasesystem of claim 22, wherein the fallout manager is further configured tocontrol the logical fields presented by the query building interface byremoving, from the data repository abstraction layer, logical fields notused in building a query within a second predetermined period of timegreater than the first predetermined period of time.
 24. The databasesystem of claim 23, wherein hiding a logical field comprises modifying aparameter associated with the logical field in the data repositoryabstraction layer.
 25. The database system of claim 22, wherein thequery building interface provides a user the option of displayingpreviously hidden logical fields.